Search


#scrum #通才

其實我真的覺得,不需要把 scrum 每個...

  • Share this:


#scrum #通才

其實我真的覺得,不需要把 scrum 每個人都得要「擁有」跨職能的能力拉高到很誇張的層次,每個人本來就有每個人擅長的東西。
即便到現在,我也仍不覺得測試人員要有開發人員的能力,開發人員要有測試人員的專業。

但 scrum 的確是基於「每個 task team 裡每個人都要能認領與處理」的前提假設,來最佳化價值產出與避免浪費。

其實,我覺得退而求其次只需要做到「每個人可以支援不同類型的任務即可」。開發人員領測試的 task, 可能沒有測試人員專業,測試人員領開發 task,開發速度與品質可能沒有開發人員快。

著重在有沒有造成問題,有沒有影響結果,「其他的都保持 open mind」的心態,能「互相支援」、「發揮綜效」、「目標一致」,是不是每個人都要全端天賦點滿沒這麼重要,應該說那個挑戰性太高跟可能性太低。

只要能互相支援,目標一致,其實 skill 是不是 generalized, 沒這麼重要。
當你強迫,有人不買單時,反而就是明顯、明確的團隊問題....這比是否具備generalized 的問題嚴重地多。

--
更何況 scrum 不是萬靈藥(沒有任何一樣東西是萬靈藥),如果該問題陷入無法解決的情況,也不需要死守著 scrum 不放,還有 kanban 適合用來做持續改善、避免浪費、找出價值流啊....

但實務上的確應該避免,有成員「只做」或「只想做」自己擅長的東西。這會對整個開發 flow 造成干擾與大影響。

這也是所謂「擁有跨職能 skill」最想解決的根本問題。只是解決問題的手法不是只有一種,每個人都擁有跨職能技能、都是全端高手,當然就沒這問題。但實務上沒這麼爽的,怎麼讓實務可行,才是最重要的事。


Tags:

About author
我是 Joey Chen,闖蕩江湖的稱號是 91,熱血點火師,專門燃起大家心裡面的熱情與初衷。 目前為 Odd-e Taiwan 的負責人,同時也是 JetBrains 在台灣的培訓夥伴,至今也仍是熱愛學習與享受各種程式語言之美的 programmer。 身為敏捷教練,擅長 Agile、Scrum、LeSS 等敏捷文化與協作框架的落實與導入,如何讓大家 being agile 而不是 doing agile。同時喜歡結合各家所長,例如 Lean, Kanban 等,重點是持續改善、解決問題、端出成果,而不執著於某種特定方法論或框架。 身為技術教練,我也是極限編程(extreme programming)的狂熱者,我擅長用這些技術與工程實踐來提昇產品的品質、團隊的生產力、降低營運風險,因應市場與公司的商業目標,讓團隊能具有高適應與反應能力的基礎建設。例如 實例化需求、ATDD、BDD、TDD、重構、自動化單元測試/整合測試/驗收測試、CI/CD、code review、pair programming、mob-programming 等等。 同時,我也是推崇 極速開發 的 developer,追求從想法到產品程式碼的完成,中間的時間差能趨近於零,也就是劍隨心轉,想到哪,程式碼就長到哪的境界。從想法到實現中間的等待,其實在實務上佔了很大的 context switch 成本,如果能讓這段時間縮到最短,就能比其他人多嘗試更多種解決方案,進而挑選出最剛好的方案。 同時也是技術社群的活躍份子,從 2010 年開始連任九屆的微軟 MVP,兼任 MSDN 論壇板主,也曾經獲得年度 MSDN 文件庫刊登數量世界第一的榮耀。對微軟技術有愛,對 C# 有愛,對自動測試有愛,對重構與設計模式有愛。近年來對 Java, PHP, Python 也充滿濃厚的興趣,曾帶領客戶團隊中不會寫程式的 QA ,一起用 Python 完成超過百個 mobile UI 自動化測試。 擁有超過十年擔任開發團隊 tech leader, trainer, coach 與 mentor 的經驗,進行的企業內部與公開技術培訓課程已超過 100 場,培訓過的開發人員超過 1000 位,擔任研討會與社群活動的講師次數超過 30 次。 同時也是技術書籍的作者與譯者,與朋友合著的書籍包含《ASP.NET MVC 5:網站開發美學》、《ASP.NET MVC 4 網站開發美學》,翻譯的書籍有《單元測試的藝術-第二版》、《敏捷開發實踐》、《進入IT產業必讀的200個 .NET面試決勝題》。 如果想跟我即時互動,歡迎直接私訊或 email 至 [email protected]
請參考:https://tdd.best/about/
View all posts